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Traffic Scheduling System 

Field of the Invention ^ 

The present invention relates to methods and apparatus for trafi&c scheduling 
5 and particularly for scheduling vehicles on road journeys. However, it also applies to 
shipping operations, aircraft as weU as rail journeys and multi-modal journeys which 
combine movement in two or more modes of transit. 

The preferred embodiment of the present invention uses two forms of trafi&c 
planning data for scheduling vehicle journeys. First, pre-event traffic pl annin g data is 

10 used in the form of a forecast of probable vehicle speed over a particular stretch of 
road at a particular tune, e.g. a particular time of the day on a particular day of the 
week. Such data is based upon analysis of actual travel times gained from the 
vehicles which traverse a particular stretch of road and the knowledge that similar 
circumstaiices may take place. Secondly, a current traffic delay reporting system 

15 provides real time data ia terms of actual vehicle speeds over a particular stretch of 
road at a particular time, e.g. a particular time on a predetermined day. Ih addition a 
feedback loop compares actual traffic speed data with the pre-event traffic planning* 
data already provided in order to improve the quality of the pre-evmt data. This 
information is useful to both traffic planners and those drivers planning and 

20 undertaking journeys in order that they may be able to accurately calculate their 
specific journey times. 

For the purposes of this specification the term "traffic planner" includes any 
person or apparatus capable of planning or imdertaking a joumey or multiple 
joumeys. The abihty to obtain hve traffic delay data also allows those planning and 

25 undertaking joumeys to re-plan and re-route vehicles in order to avoid known delay 
spots. The term "transit point" used herein means a stopping place on a joumey, for 
example for loading or unloading payloads and deUvery items. 

30 
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Background Art 

Commercial vehicle routing and scheduling methods have been in existence 
for many years, providing a minimum mileage estimate for single or multiple vehicle 
journeys of one or more drops or stopping places. One such known system is 
5 disclosed in a paper entitied "Scheduling Vehicles from a Central Depot to a Number 
of DeUvery Points" Clark, G., and Wright, J. W., Operations Research (1963), 11, 
568-581. ICnown methods, however complex, rely on the deteraiination of an average 
vehicle speed for a particular type of vehicle (for example, an articulated vehicle) over 
a defined type of road (for example, a motorway). More sophisticated systems apply 

10 congestion factors to potential travel speeds as percentage reductions in the defined 
speed between specific times on a particular day. 

In practice, vehicles travel over different stretches of any road at different 
speeds depending upon the time of day, type of vehicle, volume of traffic, restrictions 
such as road works, or specific traflSc incidents such as accidents or breakdowns. 

15 . Since actual traffic speeds are affected by traffic congestion of one type or another, 
forecast travel times used in vehicle routing and scheduling techniques are inaccurate. 

]h the commercial sector, the results of inaccurate forecasts are particxilarly 
significant upon the productivity of both the resources and staff undertaking a 
journey. In the last few years, vehicle routing and scheduling methods have lost 

20 favour with operational managers due to the gap between plaimed journey times and 
actual journey times. For example, in a commercial operation delivering orders to 
customers within required time windows, it is estimated that more than 18% time 
contingency is built in to the daily traffic plan to ensure a 98% probability of success 
in achieving all the deUveries within tibe desired time windows. Furthermore 

25 extension of the working day (ofl;en resulting in the payment of overtime to both 
drivers and warehouse staff) may be another consequence if the delivery time is 
extended due to traffic congestion. Journey planners are also criticised because the 
18% time contingency built into a traffic planning schedule results in productive time 
being wasted on a good day. 
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Therefore, to date the majority of telematics systems have been limited to cars 
and applications to support heavy goods traffic and passenger traffic have been 
largely ignored. Preferred embodiments of this invention focus upon the appUcation 
of this technology for heavy goods and passenger traffic. . However, the invention is 
5 not limited to this, the invention having appUcations in other fields, mcluding the 
non-commercial sector; such as emergency services or other commercial appUcations 
such as aircraft, rail and shipping operations etc. 

An objective of preferred traffic scheduling systems is to minimise the impact 
of both predicted and impredicted traffic delays for the commercial vehicle operator. 
10 This invention seeks to provide an in:q>roved method of scheduling traffic. 

According to a first aspect of the present invention, there is provided a melhod 
of operating a b-affic scheduling computer system for planning journeys, each journey 
having a plurality of transit points, method comprising receiving scheduling criteria 
including transit point data, receiving map data, said map data comprising one or 
15 more routes, each route defined by a plurahty of route-sections, receiving forecast " 
speed information for a traffic unit on each said route-section, the forecast speed for a 
given route-section depending on historical speed data for that route-section at a 
predetermined time on a particular day; and planning a journey including a plurality 
of transit points in dependence on the scheduling criteria and forecast speed 
20 information. 

In preferred embodiments, the scheduling criteria .comprise one or more of 
availabiUty data, distance data, time data, depot data, customer data, and product data. 
The availability data might conqjrise. for example, availabiUty information for one or 
more 6f a prime mover, a trailer and a driver. The forecast journey speeds and times 
25 .arederivedatleastinpartfromhistorical-speeddataacquiredbymeansoffloating 

vehicle data coUection units or other mobile data coUection means. Live traffic 
monitoring may also be performed by means of floating vehicle data collection units 
or other mobile data coUection means. 

According to a second aspect of the present invention, there is provided a 
30 computer system for scheduUng traffic, capable of planning journeys each having a 
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plxtrality of transit points, the system comprising means for receiving scheduling 
criteria including transit point data and map data, said map data comprising one or 
more routes, each route defined in terms of a plurality of route-sections, a data 
repository comprising historical speed data for each route-section, historical speed 
5 data for a particular route-section being represented for a predetermined time on a 
particular day, means for generating forecast speed information for a traf&c unit on 
each said route-section based on said historical speed data, and processing means for 
plaiming a journey including a plurality of transit points in dependence on said 
scheduling criteria and forecast speed information. 

10 According to a third aspect of the present invention, there is provided a 

method wherein at least a portion of the planned journey is re-plaimed according to 
re-scheduling criteria after the trajBSc unit has embarked upon the journey. Preferably, 
said re-planning step is triggered in response to an unpredicted traffic event or 
operational failure. In preferred embodiments said impredictable event data comprises 

15 live traffic reports and/or data derived from live traffic monitoring. 

According to a fourth aspect of the present invention, there is provided a 
method wherein a first journey solution is determined in a first algorithm processing 
step and an improved journey solution is determined in a further algorithm processing 
step. 

20 According to a fifth aspect Of the present invention, there is provided a method 

in which unpredictable events are categorised according to a geographic region in 
which they occur and information on the unpredictable event is communicated to 
traffic imits associated with a relevant geographical region. 

According to a sixth aspect of the present invention, there is provided a 

25 method in which forecast speed information for a route-section is recorded and 

compared with victual speed data for that route-section in order to provide a measure 
of reliabihty or feedback to the traffic scheduling algorithm. 

' According to a seventh aspect of the present invention, there is provided a 
metiiod in which floating vehicle probes are selectively activated ' for monitoring 
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based on a probabiHty of the traffic xmit carrying the probe being on a predetemuned 
route-section. 

List of Drawings 

5 The inveation wiU now be described, by way of example only, with reference 

to the accompanying drawings in which: 

Figure 1 is a schematic diagram illustrating components of a preferred traffic 
scheduling computer system; 

10 

Figure 2 illustrates a preferred system for on-board Uve data collection; 

Figure 3 schematically iUustrates componeuts for producing a Road Timetable™ data 
repository suitable for use in the traffic scheduling system of Figure 1 ; 

Figure 4 illustrates a method for determining vehicle routes suitable for use in the 
traffic scheduling system of Figure 1 ; 

Figure 5 illustrates a system for reportmg Uve traffic delays in the traffic scheduHng 
20 system of Figure 1; 

Figure 6 schematically illustrates components for dynamic vehicle re-planning in the 
traffic scheduling system of Figure 1 ; 

25 Figure 7 illustrates components for live vehicle monitoring; 

Figure 8 illustrates the feedback of data applying to a vehicle journey; 

Figure 9 illustrates a preferred system for veHcle route planning and dynamic route 
30 planning; 
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Figure 10 illustrates examples of input data for deriving a planned vehicle route; 
Figure 11 illustrates a sequential insertion based algorithm; 

5 

Figure 12 illustrates a parallel insertion based algorithm; 

Figure 13 illustrates possible improvement phases for use in the traffic scheduling 

system of Figure 1 ; 

10 ... 

Figure 14 illiKtrates a simulated annealing improvement algorithm; 

Figure 1 5 illustrates a Tabu search improvement algorithm; . 

15 Figure 16 illustrates an algorithm used to calculate the impact of potential traffic 
congestion; 

Figure 17 illustrates an algorithm for calculating the impact of customer drop delays; 
and 

20 

Figure 18 represents an algorithm which can be used for dynamic vehicle re-planning. 

Desfcription of tihe Preferred Embodiment . 

A preferred embodiment of the present invention will now be described, by 
25 way of example only. Embodiments of this invention may be used for the planning of 
routes and/or schedules for all types of transport, including but not limited to cars, 
ambulances or other emergency or miHtary velicles, heavy goods vehicles, buses, 
coaches, aircraft, shippiug and any other modes of transport. 

The traffic scheduUng computer system of Figure 1 records 4aily traffic data 
30 by section of road (for example, between specific motorway junctions). It has been 
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iBdicated that approximately 75% of congestion is predictable both in probability of 
occurrence and in the delay time expected. Such predictable traffic congestion 
includes that due to volume of traffic, road works, wide-load movements or extended 
poor weatiaer conditions. 
5 The ability to predict such pre-event traffic congestion is based upon the 

collection, interpretation, analysis and presentation of historic and forecast data both 
fiom within the public domain and from specific sources such as vehicles which are 
fitted with a probe to detect location and speed, which when coUected is known as 
'floating vehicle data' (FVD)™. The outcome of this analysis is a Ust of "pre-event" 
10 traffic delays which is an aspect of the preferred embodiment of the present invention. 
The summary of the data analysis presents a forecast of travel speeds for selected 
types of vehicles over a specific road length at specific times of the days of the week, 
known as the "Road Timetable™". Preferred, embodiments can record speeds against 
calendar dates so that all patterns of traffic behaviour can be identified. 
15 The presentation of forecast travel speeds for specific road lengths and times 

■of the day, allows the journey plamier to add this data to a vehicle routing and 
scheduling algorithm to produce more accurate vehicle travel plans. The appUcation 
of the "Road Timetable™" in a vehicle routing and scheduling method is a further 
aspect of the preferred embodiments of this invention. A vehicle routing and 
20 sdieduling method based upon the use of this type of predictable travel time for each 
section of road on a journey provides an improvement over known journey planning 
systems. However, such systems still have a degree of error between the planned time 
and the actual time which corresponds to approximately 25% of unpredictable traffic 
delays. ■ 

25 Unpredictable traffic delays, such as those caused by road traffic accidents 

(RTA) may also be identified as they occur by means of vehicle probes which are 
within the area in which tiie delays are actially occurring or from traffic reports on 
particular incidents. These unpredicted incidents may be reported separately in 
association with a geographic location, for example a section of road in a postcode 

30 sector. Such information may be sent to both traffic planners and drivers by means of 
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any suitable form of coimnunication. Actual vehicle speed in unpredicted traffic 
scenarios may be compared with the speed forecast from historic data, thereby 
making it possible to determine a new predicted delay time. The calculation and 
communication of this current traffic delay due to unpredictable events is a further 
5 aspect of tiie preferred embodiment of this invention. 

By monitoring vehicle progress in real time it is possible to report where 
traffic delays are occurring so journey plamiers can. identify or select vehicles which 
are affected by the impredicted traffic incident(s). Upon identification of a vehicle 
affected by an unpredictable traffic delay aad determination of the delay time arising 

10 firom the or each incident the information is supplied to a * dynamic vehicle re- 
planning system". The dynamic vehicle re-planning- system can for example enable 
re-routing of vehicles mid joximey to avoid the unpredicted traffic delay and/or re- 
plan the drop sequence of a delivery load. Preferred vehicle re-planning systems can 
be included within or associated with general vehicle routing and/or scheduling 

15 systems. 

Preferred traffic planning and re-planning systems are further enhanced if for 
exan:5)le multiple elements of the delivery resource (trailer, prime mover and driver) 
are considered as separate but inter-related resources. This can be facilitated by 
monitoring a prime mover and a trailer separately and using driver and vehicle 

20 recognition systems. Thus, the driver and vehicle(s) can be monitored separately. 
The driver's identity is recognisable to the data collection unit on at least the prime 
mover. Considering vehicle routing and scheduling tasks in terms of a number of 
separate resources (trailer, prime mover and driver) offers many alternatives in the 
event of an unpredicted traffic delay. The application of the knowledge of the delay 

25 time firdm an unpredicted traffic incident in the dynamic vehicle re-planning is a 
further aspect of the preferred embodiment of this invention. 

Figure 1 identifies component parts of the preferred computer system and how 
they link together. Each component part has both inputs and outputs in its own rigfit, 
a detailed description of which follows. Some componCTit parts described herein may 

30 be obtained on the commercial market firom independent vendors, the functionality 
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and construction of others will be apparent to a skilled person from the description 
herein. The preferred embodiment combiaes a nxmiber of novel aspects which 
include: the Road Timetable™ - an information resource containing forecasts of 
trafBc speeds by type of vehicle over a particular section of road on a defined day and 
5 time accounting for known traffic delays; the application of the Road Timetable™ in 
commercial vehicle routing and scheduling, the calculation and rapid coromunication 
of potential delay time in relation to unpredictable traffic delays; and the application 
of such delay time ia dynamic vehicle re-planning. In the context of this description 
the term "dynamic" means while a vehicle is enrroute, i.e. has already embarked on a 

10 planned journey. 

Referring to Figure 1, a preferred traffic scheduling system 100 comprises a 
Road Timetable™ 110. The Road Timetable™ 110 is an information resource which 
supplies forecast information taking into account historical traffic data to a Vehicle 
Route Planner 120. The forecast information is in the form of a database recording 

15 speeds by vehicle type, road section and temporal characteristics. The Road 
Timetable™ is described hereinafter with reference to Figure 3. 

The Vehicle Route Plamier 120 calculates the best route for the or each 
proposed journey, taking into account the start location, destination location and any 
transit points which may be relevant. The Vehicle Route Planner 120 and its modes 

20 of operation are described iq more detail later with reference to Figure 4. The Vehicle 
Route Planner 120 outputs an indication of the best route or routes to a Dynamic 
Vehicle Re-planning stage 130. 

The Dynamic Vehicle Re-planning stage 130 is cdpable of adjusting a route 
for a vehicle which is already embarked on a route deternnned for it That route may 

25 have been determined by the Vehicle Route Planner 120 or an earlier re-plaoning 
process of the dynamic re-planaer 130. The dynamic re-plaraiing stage 130 receives 
information firom a live delay reporting facility 140 and a Live Vehicle Monitoring 
Facility 150. The Live Vehicle Monitoring Facility 150 measures a real time delay by 
recording current vehicle speeds by means of vehicle-bound, i.e. "on-board" data 
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collection units (DCUs). Tbis collection of data is represented by box 160 of Figure 
1. 

Further descriptions of the Dynamic Re-planning stage 130, the Live Delay 
Reporting Facility 140, the Live Vehicle Monitoring FaciHty 150, and the on-board 
data collection units are provided hereinafter with reference to Figures 6, 5, 7 and 2, 
respectively. 

' In this embodiment, the route determined by the traffic scheduling System 100 
is output from box 130 to the hand held terminal as described in Fig. 6 but this 
configuration should not be limiting and different communication means may be 
©cnployed in other embodiments. 

A Post Trip Data Module 170 receives route mformation from the Dynamic 
Vehicle Re-plarming stage 130 and the Live Data Collection Units represented by box 
160. These mpvAs are processed and results fed back to the Road Timetable"^ 110 
and Vehicle Route Planner 120. The processing performed by the Post Trip Data stage 
170 compares a log of actual delays occurring over time with the planning and re- 
planning information output at the . corresponding time so that deviations can be taken 
into account in the next schedule determination. This is described in more detail with 

referaice to Figure 8. 

Figure 2 illustrates the technique by which a vehicle collects live data about its 
position and operational characteristics. This technique is described because the 
characteristics of Uve data are used in the generation of the Road Timetable'^ 110 
and in the determination of unpredicted traffic delay. A vehicle which contains a data 
collection unit is referred to herein as a "probe" vehicle. 

The precise location of a probe is defined by its latitude and longitude. This is 
obtained through calculations on information derived from a Global Positioning 
System (GPS) receiver fitted to the vehicle. The GPS receiver obtains at least three 
direct line of site readings from the GPS SateUites 220 using a well known technique 
to obtain an accurate vehicle location. In Europe such GPS receivers may be obtained 
from a number of commercial supphers produced under the Global Automotive 
Telematics Standard (GATS) issued by.Comit6 Europeen de NormaUsation CEN. 
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Similar receivers known outside Europe are suitable for use in accordance with the 
presait invention. 

A combination of vehicle positions obtained at predetermined time intervals 
throughout a journey, is known as Floating Vehicle Data 210. This Floating Vehicle 
Data 210 is the basis for the calculation of vehicle speed and direction of travel at a 
particular position. 

In this embodiment, each probe contains means for transmitting location 
information and/or information derived therefrom to a central data collection point 
240. Floating Vehicle Data 210 may be accumulated on-board the vehicle by a data 
collection unit 230. This may be stored in a suitable vehicle-bound storage device or 
transferred to another suitable storage device, such as a Hand Held Terminal (HHT) 
or a Personal Digital Assistant (PDA) 250. Alternatively, or in additions, the Floating 
Vehicle Data may be transmitted directly from the data collection unit to a cential 
data coUection station 240. Uve data may alternatively be sent to the central data 
collection point 240 via a HHT/PDA 250 by immediate communication ushig, for 
example, Short Messaging Service (SMS) or General Packet Radio System (GPRS). 
A skiUed person would be able to select a suitable communications configuration for 

a particular application. 

Where Floating Vehicle Data 210 is accumulated on board, it may be held on- 
board 230, for example in a Hand Held Temiinal (HHT/PDA) 250 for the driver or 
• passenger to use as part of an independent navigatibn system. In ttiis case, data from 
the HHT 250 may be -transferred to the Data Collection Station 240 later by any 
suitable means including, but not limited to, historic data direct base station or radio 
download upon return to base. 

Live data from the Data Collection Station 204 may be used by a Vehicle 
Scheduler 260 to track the progress of vehicles on their predefined route. Historic data 
will be obtained from the On-board Data Collection ftmction 230 and analysed as Post 
Trip Data 170 to update the Road Timetable ™ (see Figure 8). 

Figure 3 is a schematic diagram' illustrating the Road Timetable"^ data store. 
The positional data is collected throughout a journey from a plurality of Vehicle 
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Probes 310. The Vehicle Probes 310 are distributed over a predetermined 
geographical area permitting the calculation of historic average vehicle speeds for 
different types of vehicles on speciJ&c road sections at specific times of the day on 
particular calendar days. In addition, or iq the altemative, traffic data may be collected 

5 firom other sources such as fixed sensors or another technology indicating location 
(e.g. mobile phones). This historical data resource is called Historic Floating Vehicle 
Data 320. Historic Floating Vehicle Data 320 is presented as forecast vehicle speeds, 
classified by type of vehicle and by time of day on a predefined stretch of road. For 
example, oatries in the Road Timetable™ 110 may indicate the historic average speed 

10 of a fireight vehicle, at 15 minute iatervals, on the portion of the Ml between junctions 
19 and 20, Northbound). The Historic Floatiag Vehicle Data 320 is passed through a 
number of statistical analyses stages to detennine the average speeds from the 
plurality of detected vehicle probes 310 for each vehicle type at specific time intervals 
(e.g. every 15 minutes) and to. place more statistical weight upon tiie more recently 

15 collected data. 

The infonnation in the Road Timetable™ UO'is thus the presentation of the 
historic traffic speeds averaged over a time period for a specific road length at specific 
times. This data thus incorporates all predictable traffic delays due to factors such as 
volume induced congestion of traffic or long term road works. The iafomiation in the 

20 Road Timetable™ 1 10 is presented such that it can be used in the process of planning 
vehicle routes and schedules 120. Further, Post Trip data 170 is fed biack to enhance 
the Historic Floating Vehicle Data 320. The Road Timetable™ 110 also contains 
additional data relevant for planning yehicle routes for vehicles of various types. This 
additional data can be obtained firom sources in the public domain 510 and/or from 

25 sources outside the public domain 520. 

The information contained in Road Timetable™ 110 may include different 
types of information which may be presented in many differmt forms. The Road 
Timetable™ 110 is preferably presented in electronic form and the data updated 
periodically by means of a web browser or other suitable means. 
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Users may choose from a number of criteria known to traffic planners, for 
example, whether the following infonnation should be made available: 
Road link identification means 
Link length 

Day of the week (of which eight are recognised, namely Sunday to Saturday 
and Bank Holiday) 
Time of day (in defined intervals) 
Speed through link 
Delay (time) 
10 • • Reason for delay (if known) 
Vehicle type 
Libound links 
Outbound links 

Restrictions in link (for example, low bridge or level crossing) 
15 • Restrictions for use (times when heavy goods vehicles restricted) 

Weight restrictions 

Bridge height or road width restrictions 
Toll charges 

The appUcation of the Road Timetable™ 110 to the process of planning 
20 vehicle routes 120 gives a high level of accuracy in forecasting vehicle speeds for 
each type of vehicle over a specific road length at a specific time on a predetemuned 
. calendar day. For a given type of vehicle, summing the forecast average speeds over 
the pluraHty of defined road sections of a journey allows the calculation for expected 
total driving time on a proposed journey. This is a usefid measure because the total 
25 driving time in a day is restricted by law in many countries, particularly for drivers of 
heavy goods vehicles and coaches. 

Figure 4 describes how vehicle routes are planned by the traffic scheduling 
system of Figure 1. In this example, separate resources of a commercial heavy goods 
operation are regarded as the vehicle (prime mover), the trailer and the driver. This 
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approach to resource management is useM because a round trip for a trailer carrying 
a deUvery load may consist of a deUvery to one or more locations and collection of 
product from one or more locations, with such locations being visited over one or 
more days and requiring a substantial total mileage to be covered. However, such a 
trailer may be puUed by more than one prime mover and utilise more than one driver 
to complete the journey. Although the example given is directed to commercial heavy 
goods, this is not intended to be Umiting. The invention also applies to a multitude of 
other fields, examples include aviation, rail, shipping, mihtary or emergency services, 
where other types of separate resource, such as vehicles and crew, might be required. 
Preferred embodiments also include conmiercial and non-commercial uses, in which 
it might only be necessary to monitor either the vehicle or the trailer. 

The inpvA parameters 610 for a preferred initial routing and scheduling 
algorithm 450 include, but are not be limited to: data from the Road Timetable 110, 
characteristics and availability data 410 of the vehicle; trafler and driver, depot 
locations 430; customer orders and constraints 420; initial time and distance matrix 
440 between aU customers drop points, collection points and the depot locations. The 
distances of the time and distance matrix 440 are calculated by means of an electronic 
road m^ using the shortest distance routes between relevant transit poiats. 

These parameters are used by the initial routing and scheduling algorithm 450 
20 to provide initial vehicle routes. Therefore in preferred embodiments, information 
from the Road Timetable™ 110 is input to a routing and scheduling algorithm 4§0 to 
provide optimised routes based on accurately predicted travel times. The routing and 
scheduling algorithm 450 outputs the optimised route and predicted travel times to a 
scheduler interface unit 460. The scheduler mterface unit 460 has an interface 
allowing, where desired, manual adjustinent of parameters and reprocessing of the 
routing and scheduUng algorithm 450 to provide accepted planned vehicle routes 470. 
Therefore it is not mandatory for an operator to accept the recommended rbutes(s) and 
he may instead wish to impose criteria, route sections and/or entire routes. M this 
embodiment, the accepted vehicle routes 470 are the basis for botii the fleet 
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p^foimance reportmg 480. via mcoiporation into a. post-trip data 170, ar.d auy 
subsequent dynamic vehicle re-planning 130. 

m the initial routing and scheduling algorithm 450 vehicle speed is input via 
parameter 410 and is apphed to calculate the travels from the time and distance matnx 
440 The ^pUcation of Road Timetable™ infonnation 110 as a parameter m the 
initial routing and scheduling algorithm 450 allows speeds along the route considered 
in the algorilhm to be represented as a forecast speed for each specific road length at 
the appropriate time in Ihe relevant day of the week. .The apphcation of the Road 
Timetable™ infonnation 110 in this way may make one or more routes unfeasible 
owing to the available drivers time input as one of the characteristics and driver 
availabihty parameters 410. Under such circumstances the algorithm will utihse 
specific operations research techniques, such as parallel insertion or Tabu search 
(shown later in figures 12 & 15 respectively), to reallocate customer orders and 
customer collections to alternative vehicles. 

For implementation reasons, a skilled person may decide to process Road 
Timetable information 110 as a fiirther phase performed after an initial processing of 
the vehicle routing and scheduling algorithm 450. as will be described in more detail 
hereinafter. A skilled person will appreciate there are other ways of incorporating 
Road Timetable™ information 1 10 into the routing and scheduling process. 

Figure 5 illustrates fiinctions of the Uve traffic delay reporting stage 140 which 
compares the actual (real time) traffic speeds from individual vehicle probes 
providing Floating Vehicle Data™ 210 with the forecast traffic speed (by type of 
vehicle) reported on tiie Road Timetable™ 110. 

• The Traffic Alert Generator™ module 550 is tiie comparison and quahty 
control routine from which the Uve delay reporting information 560 is generated. 
Tins module can identify unpredicted traffic delays as well as inq,rovements in tiraffic 
speeds having regard to the record in tiie Road Timetable. In this embodiment, the 
Traffic Alert Operator™ 550 first selects vehicle probes, preferably based on a 
probabihty fimction reflecting the Hkelihood of the vehicle being on the relevant road 
section, to detemiine in real time from the selected vehicle probes specific aspects of 
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Floating VeHcIe Data 210. In this example, the criteria sampled include the traffic 
speed by vehicle type over a specific road section at a specific time of the day. These 
criteria are compared with the forecast speed by type of vehicle on the corresponding 
road section at the appropriate time on the same day from the Road Timetable 110. 

5 Any significant deviation is indicated by the Traffic Alert Generator to the Congestion 
Scheduler by means of traffic delay incident reporting 540 and recorded within the 
Traffic Alert Generator for Uve delay. reporting 560 to either tiie Vehicle Scheduler 
260 or direct to a driver 570. 

The actual live data obtained from the vehicle probes or other sensor data 580 

10 is compared wilix the predicted speed held in the Congestion Scheduler™ 530 and any 
significant variance reported back to the Traffic Alert Generator 550 through the five 
delay reporting 560 system. The Congestion Scheduler™ 530 is a database of known 
incidents which are likely to cause traffic delays. The data on each incident recorded 
in the Congestion Scheduler™ is obtained eitha: from the public domain 510 or from 

15 a source outside the public domain 520. An example of a source outside the pubUc 
domain is a police force proyiding an escort for a slow moving wide load, such a 
source typically being able to provide speed and route information. The Congestion 
Scheduler™ 530 also includes a database of earlier incidents to apply 'artificial 
inteUigence' techniques to predict potential delays incurred by an incident from the 

20 moment one is detected. The Congestion Scheduler™ 530 is issued to users as a 
separate database or is available on the Internet or the hke. When the reason for a 
traffic delay incident 540 is established and verified by other sensor data 580 or the 
traffic alert generator 550, tiien the information is passed to the Jive rq)orting system 
560. 

25 Following the determination of a traffic delay by the Traffic Alert Generator 

550, the live delay reporting system 560 sorts the delays by geographic zone, for 
example by postcode (zip code or other area classification means) and reports these 
to drivers 570 in the relevant post code (zip code or other geographical zone) by 
means of a suitable communication system, such as SMS or GPRS, possibly utilisiiig 

30 HHT or PDA 250 or a Radio Traffic System - Traffic Messaging Centre (EIDS-TMC). 
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The live delay reporting system 560 also reports the geographically classified delays 
to vehicle schedulers in step 260. Where a vehicle schedider is a person the delay may 
be reported, for example, direct to a desk top computer in order that they may take- 
on-route vehicle re-plamiing 130. Where the scheduler is a computer implemented 
5 system, the delay may be reported to an appropriately figured Applications 
Programmer Interface (API), for example to the dynamic vehicle re-routing module 
130 of Figure 1. 

All incidents logged in the Traflic Alert Generator® 550 are monitored by 
means of Floating Vehicle Data 210 until the incident is cleared. This type of historic 

10 data is also maintained in the database to be used as part of an * artificial intelligence' 
system to predict the length, in time, of any incident on a specific journey. By 
comparing real time Floating Vehicle Data 510 indicating actual vehicle speed over a 
specific road section at a specific time of day on a specific day of the week with the 
forecast vehicle speed calculation in the Road Timetable™ 110, which is classified in 

15 the same way, unpredicted trafl5c delays or xmpredicted improvements in traffic 
speeds are identified as occvirrences which produce a significant variation. The 
identification, verification, calculation and reporting of such occurrences or incidents, 
with reasons, to users or route-plaiming/re-routing applications is a usefiil service. 

Figure 6 describes the dynamic vehicle re-planning process 130 which is 

20 employed when significant unpredictable traffic delays occur. Such re-routing may 
be necessary in the event of unpredicted trajSfic delays in commercial heavy goods 
vehicles for example in ordCT to either achieve the customer service levels required or 
to maximise the drivers' potential driving time within recognised legal limits, if any 
apply. However, as noted above, this is not limited to conmiercial heavy goods 

25 systems. Dynamic vehicle re-planning could feasibly be of use in a variety of other 
systems including the examples noted above. In practice, a maximum tolerable length 
of unpredictable delay is predetermined and when this threshold is exceeded a re- 
planning process is initiated. The value of the threshold in time depends on the 
application. 
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From a knowledge of vehicle routes in use 470, unpredictable live trajBSc 
delays reported by geographical zone 560 and the existing vehicle schediiling 
parameters 610 it is possible to re-route vehicles akeady raibarked upon planned 
journeys using a dynamic vehicle re-routing and scheduling algorithm 620. The 
5 purpose of the dynamic re-routing and scheduling algorithm 620 is to provide a new 
route for undertaking all planned stops for any vehicle which is subject to an 
unpredicted traffic delay. This process depends upon being able to indicate the 
current position, direction and speed of a delayed vehicle by means of a probe and 
live vehicle progress monitoring 150. 

10 The dynamic vehicle re-routing and scheduling algorithm 620 determines a 

number of new route options by means of 'artificial intelligence* in a predetermined 
priority order for each vehicle effected by an unscheduled traffic delay or 
improvement in traffic speed above that forecast in the Road Timetable™ 110 used in 
the calculation of the original pre-event planned routes 470. The dynamic vehicle re- 

15 routing and scheduling algorilhm 620 may consider, for example, one or more of the 
following options in the event of a delay: 

• Extending the drivers driving and working time to maximum permitted hours in 
that day or the next day. 

• Despatching another driver (with sufficient driving and working time available) to 
20 a pre-selected point to relieve the first driver and complete tiie work. 

• Deleting one or more collection and using another vehicle combination to 
imdertake this work. 

• Delaying a non-critical customer drop until the next day. 

• Returning a customer drop, duplicating the order picking and sending another 
25 vehicle combination out later to undertake the delivery. Returning the original 

order to stock upon return of the delayed vehicle combination. 

• Dropping the trailer at pre-selected point for another driver to collect and 
complete the work (including drivers of third-party operators). 
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• Dropping the trailer at pre-selected point and asking the customer to collect it and 
deUver the load (for example if a third-party logistics firm midertakes the 
collection and delivery for the customer). 

The dynamic re-routing and scheduUng algorithm 620 will present alternative 

5 solutions to a vehicle scheduler interface 607. The scheduler interface 607 confirms 
the recommended changes or .can select an alternative. Once the vehicle scheduler 
607 has confirmed a selection the dynamic vehicle re-planning module 130 will 
communicate to the drivers concerned 250 actions to taken by the selected 
coimnunication means, for example, SMS or GPRS. 

10 The dynamic re-routing and scheduliag algorithm 620 stores the selected 

changes to track the progress of the changes at selected tinie intervals. The stored 
changes are also available in title database for the 'artificial intelligence' function- The 
tracking of the vehicle ("prime mover") and the load ("trailer") are preferably 
undertaken separately, in accordance with the separate consideration of these entities 

15 in the re-routing and scheduling algorithm 620 (and the routing algorithm 450). This 
allows efficient routing, and scheduling when for example a new prime mover collects 
a trailer and completes the work or another driver is despatched to complete the work. 
In the event that progress monitoring of a change shows, furtiber delays outside the 
accepted parameters then an exception message will recommend to the scheduler 460 

20 that the route is re-planned again. This process may be reiterated for either a single 
vdncle or vehicle-load combination as well as for multiple vehicles and vehicle-load 
combinations. 

Following the identification of a significant unpredicted traffic variation the 
- application of tiiie on-route vehicle re-planning, by means of a combination of 
25 dynamic vehicle routing and scheduling techniques and, optionally, 'artificial 
intelUgence' techniques together with communications to the vehicle and the 
monitoring of the vehicle progress (or vehicles progress) after the route re-planning 
process provides a significant increase in performance with preferred embodiments. 
Figure 7 describes the live vehicle monitoring system 150 which is required in 
30 order to both determine the radstence and extent of any unpredicted traffic delays and 
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to confinn the location, direction and speed of the vehicle for on-route vehicle re- 
planning and monitoring requirements. 

The vehicle scheduler 260 knows the planned vehicle route 470 and checks the 
progress of any vehicle on a pre-defined vehicle route 470. This is achieved using Uve 
5 tracking through a data collection point 240 receiving on-board information 230 from 
the vehicle probes on either (or both) a vehicle 710 or a trailer 720. This Uve tracking 
data is required for the scheduler to map the progress of a vehicle aad/or the trailer 
150 and to determine whether to undertake dynamic vehicle re-planning 130 in the 
event of a traffic delay or improvement. Live vehicle monitoring also allows the 
10 vehicle scheduler to confirm. that a vehicle or trailer is heading towards or is in a 
reported traffic delay. 

Figure 8 identifies the post trip data 170 requirements and is essentially a 
feedback loop providing \xp to date data for the Road Timetable™ 1 10. Post trip data 
170 is collected firom two sources: firstly, floating vehicle data collection 810, for 
15 example from the vehicle probes either collected Hve or stored on the vehicle and 
downloaded as required and secondly, data &om the dynamic vehicle re-planning 130 
process. All data co.Uected is vaUdated 820 and then presented in a post trip database 
170. The post trip data is subsequently used to both up date the Road Timetable 
110 and to provide fleet performance reporting 480 including comparing actual 
20 activity from the Floating Vehicle Data 810 with the planned vehicle routes 470. 

. The: activities of collection, validation and application of the post trip data 
feciHtate updating of the Road Timetable™ 110. This process also measures the 
quality of information &am the Road Timetable™ 110, when fliere were no 
unpredicted incidents, by virtue of it being a measure of the diflference between the 
25 predicted traffic speed as indicated in the Road Timetable™ 1 10 and the actual traffic 
speeds achieved over a specific road length at specificlhnes of the day for a particular 
day of the week. The post trip data 170 is also used as a quality check upon the data 
initially presented and used. 

Figures 9-18 show in more detail a preferred embodiment for a method and 
30 system for traffic planning and dynamic vehicle re-planning. 
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With reference to Figure 9, the initial data scheduling parameters 610 are used 
to run a primary algorithm 910 and then a secondary algorithm or algorithms 920. 
This provides initial results 930. These initial * results 930 are then subject to 
consideration by the scheduler interface 460 using configured data 940 and/or 
5 adjusted restilts 950. There is then the option to use either or both the initial results 
930 or the adjusted results 950 as the input data for a tertiary algorithm 960 or 
algorithms 970. These tertiary algorithms may represent further improvement phases 
so as to further modify the residts previously achieved. Alternatively they may also 
combine new data 980 (which naiay, for example, include live delay reporting 560 

10 and/or live vehicle progress monitoring 150), enabling previous results 930 and 950 to 
be modified in accordance with changes in circumstances, for example to isnable 
dynamic vehicle re-planning 130. 

Figure 10 illustrates the input data requirements for deriving a planned vehicle 
route 470.- These include but are not limited to: 

15 • a distribution depot 1010 referenced by location and activities; 

• the territory broken into geographical zones by a number of postcodes or other 
means 1020; 

• customer database 1030 giving for example, address, access times, access 
restrictions and type of mechanical handling equipment if required; 

20 • data on vehicle speeds 1040 combined with a map 1050 referred to herein as a 
road timetable 110; 

• the use of depot locations 430 and road timetable 110 to produce a time and 
distance matrix 440; 

• a table of orders classified into priorities by, for example, customer grouping or 
25 day of the week for delivery 1060; 

• products data 1070 classified for example by priority of delivery or amount; 

• policies and procedures 1080 which for example, outline vehicle loading 
restrictions for each product group ; 
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• opCTating rules 1 090, either for the product (for example, temperature at which the 
product must be carried), or for the vehicle (for example, weight restrictions and 
lorry bans); 

• vehicle availabiUty 10100 described for example, by vehicle type, carrying 
5 capacity and/or operating shifts for which they are available for use; 

• driver availability 101 10 described for example, by vehicle Ucence class, training 
level in mechanical handling equipment and/or shift availabihty .(according to 
contracts of employment and prevailing drivers' hours rules); . 

• trailer availability 10120 described for example, by carrying capacity or 
10 . specificity of goods. 

This combination of data may then be input into the routing and scheduling 
algorithm 450, which may be a series of algorithms. 1130 for example a primary 
algorithm 910 and a secondary algorithm 920 or fmther algorithms. Such algorithms 
may for example be a sequential insertion based algorithm or a parallel insertion 

15 based algorithm depending on preference. 

Figure 1 1 displays a possible sequential insertion based algorithm which might 
be used as a primary algorithm 910. This utilises a series of sequential questions 
answered by reference to liie input data shown in Figure 1 0. Beginning at start 1110a 
first question is asked 1 120. Is a seed order available? A seed order is an unscheduled 

20 customer order in the furthest geographical zone firom the depot. If the answer is no 
the algorithm stops 1130 as there is no order to process. If flie answer is yes, the 
algorithm moves on to question 1140, .... is a vehicle available? If the answer is that 
there is no vehicle available, the order is added to a list of orders not scheduled 1150. 
If the answer is yes the algorithm checks if the order can be delivwed 1 160. Again, if 

25 the answer is no as the order cannot be delivered it is added to a Ust of orders not 
scheduled 1150. If the answer is yes the algorithm checks if the trailer capacity is full 
1170. If the answer is yes, the trailer capacity is full, this may be filed as a 
preliminary route 1 180. If the answer is no the algorithm looks to see if the driver 
shift is fully utilised 1 190. If the driver shift is fiilly utilised, the algorithm checks if a 

30 • smaller vehicle is available 11100. If the answer is no then this may be filed as a 
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preliminary route 1180. If the answer is yes the algorithm returns to the question 
1160 and moves through the process again. Alternatively if the answer to question 
1190 is no then question 11120, is there another order in the zone, is asked. If the 
answer is yes the algorithm returns to question 1160. If the answer is no this is then 

5 filed as a preliminary route 1180. 

Figure 12 represents a possible parallel insertion based algorithm which may 
be used as an alternative, or in addition to, the sequential insertion based algorithm 
shovm in Figure 11. "Beginning at start 1210 a seed order is selected 1220. The 
algorithm then checks if the vehicle capacity is available 1230. If there is no vehicle 

10 capacity available this is added to a list of orders not scheduled 1240. If capacity is 
available the algorithm then checks to see if the order can be delivered 1250. If tiie 
answer is no the selected seed order 1220 is added to a list of orders not scheduled 
1240. If the answer is yes the algorithm checks if all vehicles are full 1260. If the 
answer is yes this may be filed as a route 1270. If the answer is no the algorithm 

15 checks whether there are xmscheduled orders 1280. If the answer is yes the algorithm 
returns to question 1250 and moves through the process again. If the answer is no the 
algorilhm checks if the order could be inserted 1290. If the answer is no the 
algorithtn stops 12100 as the order camot be delivered. If the answer is yes the 
algorithm either selects the next order in the zone or the next seed order 12110, and 

20 returns to question 1220. 

Once filed as a route the scheduler interface 460 may accept these routes. In 
which case routes 1180 or 1270 will become a planned vehicle route 470. A 
scheduler interface 460 may also decide to accept a stop result 1130 or 12100, or an 
addition to the Ust of orders not scheduled 1150 or 1240. Altematively, the scheduler 

25 interface may decide to utilise one or more improvement phases, as described having 
regard to Figures. 13-15. Each improvement phase will aim to reduce overall 
operating costs further and be targeted at a specific new requirement or requirements. 
Each improvement opportunity may require a specific operations research technique 
to provide an acceptable solution which reduces costs. 
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Figure 13 illustrates a numbei: of options for improving the first solution 
produced by employing one or more improvement phases. Type one improvement 
phase 1310 involves running an additional algorithm in order to improve the solution 
already provided. When used alone this may be a tertiary algorithm 960 or may 
5 involve multiple tertiary algorithms, for example 960 and 970. An example of such 
algorithm might be a Tabu search algorithm (see Figure 15) aud/or a simulated 
Amealing algorithm (see Figure 14). When type one improvement phase 1310 is 
used with an additional improvement phase, the second algorithm may involve 
repeating the initial algorithm or algorithms 10130 v/ith modified data. This may be 
10 instead of or in addition to the use of a tertiary algorithm 960 or algorithms 960 and 
970. 

A type two improvement phase 1320 involves manual intervention, changing 
or adding to the input data to produce configured data 940. This may then be used to 
rerun the algorithms already in use 10130. Note that as an alternative embodiment to 
15 manual intervention a type two improvement phase could instead be based around a 
computer facihtated intervention. 

A type three improvement phase would involve selecting a depot for which the 
dehvery is to be made to each customer 1330. This may be in response to changes in 
demand or stock or resource availability 1340. In this improvement phase a customer 
20 order 420 may be spht and deUvered directly (or indirectly) firom two or more depots. 

Type four improvement phase 1350 involves correcting the input data where 
alternatives are known and data gathered upon the previous vehicle runs. For 
example this would include the use of telematics data 1360 to correct the speed of a 
. particular type of vehicle of a defined stretch of road at a specific time of day as 
25 recorded in a road timetable 110 (see Figure 1 7). 

Type five improvement phase 1370 assesses the impact of using altemative 
resources 1380 for example different vehicle size configurations of specific changes 
in input data such as the impact of customer drop time delays. 

Type six improvement phase 1390 alters the data so as to assess the impact of 
30 the changes in customer demand 131 00. 
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By adapting the data and running multiple algorithms as described above a 
variety of commercial traffic scheduling issues can be addressed via generating the 
customer specific data entry at the front end, suitable selection of algorithm running 
times (to obtain speed of response) and a security of the solution being addressed by a 
5 selection as a requirement by the user, each requirement being solved by a specific 
algorithm and providing specific outputs. 

The various algorithms allow the user the option of limiting cost by means of 
either mininaising the number of vehicles used or by niiiiinaising the number of miles 
travelled. Each algorithm is designed to prepare the data then once set up by the 
10 operator have a run time of less then one minute on present computing systems for a 
500 customer order problem and less than two and a half minutes for a 1000 customer 
order problem. Figures 14-18 show a variety of algorithms which may be used m 
practice. 

Figure 14 represents a possible simulated annealing improvement algorithm. 

15 Starting at 1410 the total running time is first set 1420. A scheduled order is selected 
at random 1440 from a list of prelimitiary routes 1430, The algorithm checks to see if 
it is a feasible insertion 1450. If not and there is still time available 1470 another 
order is selected at random 1440 and the process begins again. If there is a feasible 
insertion 1450 the algorithm then checks if this route is better 1460. If not and there 

20 is time available 1480 then the algorithm returns to 1440 and carries on. If there is no 
time available the algorithm stops 1490. If the route 1460 is better the algoritimi then 
checks if the move is allowed 14100. If it is allowed it is thw filed as a route 141 10. 
If not the algorithm checks if the set time available is finished 1470 by returning to 
1440 if there is time available or stopping 1490 is the time available is finished. 

25 Figure 15 represents a possible Tabu Search improvement algorithm. Starting 

at 1510 a Ust of preliminary routes 1520 is used to reschedule the routes against 
objectives in a table 1530. The total nmning time of the first Tabu search has been 
previously set 1540 and if the time available is then finished the algorithm comes to a 
stop 1550. If time available is not finished 1560 the algorithm then selects the best 

30 move firom the objective table rules 1570 - these are a set of key parameters defined 
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by the scheduler. The algorithm checks if this move is allowed 1580. If not the 
algorithm returns to 1570 to select the best remaining rules in the objective table 
rules. If the move is allowed the algorithm completes the move 1590. This is then 
filed as route 15100. More Tabu are then set by changing the key parameters and the 
5 algorithm returns to 1530 and moves through the process again. 

Figure 16 represents an algorithm used to calculate the impact of potential 
traffic congestion. Starting at 1610 a route is selected 1620 from a file of preliminary 
routes 1630. Historic time and mileage forecasts 1640 are built up by subjecting data 
derived from on board data collection 230 to telematics data analysis 16100 to 

10 piDduce a road timetable 1 10. The historic time and mileage forecasts 1640 are then 
derived from this road timetable 110. A comparison of this route is made with a start 
time and mileage forecasts 1640 to check if the route is now feasible 1650. If the 
route is feasible it is filed as a new route 1660 and the algorithm returns to 1620 
selecting a new route to repeat the process. If the route is not feasible 1650 the route 

15 is recalculated using an unproveinent algorithm 1660. The resultant data is then 
inserted into the time and mileage matrix 1670, the system then returning to 1640 to 
repeat the process. If after recalculating with an improvement of algorithm 1660 all 
the routes are checked 1680 then the system stops 1690. If all the routes are not 
checked the system returns to 1620, selecting a new route to repeat the process. 

20 Figure 17 illustrates an algorithm for calculating the impact of customer drop 

time delays. Starting at 1710 a customer order is selected 1720 from a file of 
preliminary routes 1730. Data collected from on board data collection 230 is 
subjected to telematics data analysis 1740 and combined with customer parameters 
1750 to produce a customer drop time database 1760. The selected customer order is 

25 then fed into the customer drop time database 1760. The algorithm then checks if the 
customer drop time is set to zero 1770. If. it is, average fixed and variable drop time 
ass\miptions are used 1780. If the customer drops time is not set to zero then the 
actual data of the customer drop time is used 1790. In either case this produces 
customer drop time data 17100. Using this data 17100 to indicate the time delay, the 

30 algorithm then checks if this order could be inserted 17110. If not the algorithm then 
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returns to 1720 selecting a new customer order and repeating the process. If, taking 
into account the delay time, the order could be inserted 17110 the order is then jSled 
as a new route 17120 and the algorithm either stops 17130 or returns to 1720 to select 
anew order to repeat the process. 

5 Figure 18 represents an algorithm which can be used for dynamic vehicle re- 

planning. Starting at 1810 a route is selected 1820 from a file of current routes 1830. 
The route selected is in an affected zone 1820. The ajffected zones are determined 
1840 jarom the use of on board data collection 230 and incident reporting 540 by the 
traffic alert generator 550. The traffic alert generator 550 allows new time and 

10 mileage based upon actual data to be inserted into the selected route 1850, The 
algorithm then checks if this new route is feasible 1860. If the route is still feasible 
then the algorithm selects a new route 1870 and repeats the process. If the change 
indicated by the traffic alert generator means that the selected route is now no longer 
feasible the route is recalculated usiQg an improvement algorithm 1880. The output 

15 from this is then filed as a new route 1 890. The algorithm then checks if all the routes 
are checked 18100. If not a new route is selected 1870. If all the routes are now 
checked the algorithm stops 18110. 

It can be seen then that through a combiaation of real time monitoring from a 
variety of sources, the use of historical traffic data, and the selection of appropriate 

20 modifications and algorithm manipulations, routes can be planned and dynamically 
adjusted, taking into account a wide variety of different requirements, conditions and 
changing circumstances. Preferred embodiments thus benefit from a combination of 
the predicted traffic speeds offered by the Road Timetable™ used in pre-event 
planning of vehicle routes and schedules and live vehicle tracking which forms part 

25 of the live traffic delay reporting, which takes into account unpredicted traffic delays 
or improvements providing an opportunity for dynamic vehicle re-routing. Li 
addition, the collection of post trip data is used to refine ftiture predictions. 

Particular advantages of the preferred embodiments iuclude collection and 
appHcation of traffic data for use in pre-event planning of vehicle trips and post-event 
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real time re-planning in the event of an unpredicted traflSc incident occurring while 
the vehicle is on its planned trip. 

The various apparatus modules described herein may be implemented using 
general purpose or application specific computer apparatus. The hardware and 
5 software configurations indicated for the purpose of explaining the preferred 
embodiment should not be limiting. Similarly, the software processes running on 
them may be arranged, configured or distributed in any manner suitable for 
performing the invention as defined in the claims. 
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CLAIMS 

1 . A method of operating a traffic scheduling computer system for planning 
joximeys, each journey having a plurality of transit points, the method comprising: 

receiving scheduling criteria including transit point data; . 
5 receiving map data, said map data comprisiag one or more routes, each route 

defbaed by a plurality of route-sections; 

receiving forecast speed information for a traffic unit on each said route- 
section, the forecast speed for a given route-section depending on historical speed 
data for that route-section at a predetermined time on a particular day; and 
10 plaiming a journey including a plurality of transit points in dependence on the 

scheduling criteria and forecast speed information. 

2. A method as in claim 1, wherein at least a portion of the planned journey is. re- 
planned according to re-scheduling criteria after tiie traffic unit has embarked upon 

15 thejoumey. 

3 . A method as in claim 2, wherein said re-planning stqp is triggered in response 
to an unpredicted traffic event or operational failure. 

20 4. A method as in any preceding claim, wherein one or more of said planning or 
re-planning steps depends on unpredictable event data. 

5. A method as in claim 4, wherein said unpredictable event data comprises live 
traffic reports. 

25 

6. A method as in claim 4 or 5, wherein said unpredictable event data comprises 
* data derived from live traffic monitoring. 
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7. A method as in any preceding claim, wherein a first journey solution is 
detemiined in a first algorithm processing step and an improved journey solution is 
detennined in a further algorithm processing step. 

5 8. A method according to any preceding claim, wherein said scheduling criteria 
comprise one or more of: availability data; distance data; time data; depot data; 
customer data; and product data. 

9. A method according to claim 8, wherein said availability data comprises 
10 availability data for one or more of: a prime mover; a trailer; and a driver. 

10. A method as in any of claims 3 to 9, wherein unpredictable events are 
categorised according to a geographic region in which they occur and information on 
the unpredictable event is communicated to traffic units associated with a relevant 

15 geographical region. 

11. A method as in any preceding claim, wherein said forecast speed information 
for a route-section is recorded and compared with actual speed data for that route- 
section in order to provide a measxire of reliability. 

20 

12. A method as in any preceding claim, wherein said forecast speed information 
for a route-section is recorded and compared with actual speed data for tiiat route- 
section in order to feedback an input to the traffic scheduling system. 

25 13. A method as in any preceding clainot, wherein historical speed data is acquired 
by means of floating vehicle data collection units or other mobile data collection 
means. 
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14. A method as in any of claims 3-13, wherein live trafiSc monitoring is 
performed by means of floating vehicle data collection units or other mobile data 
collection means. 

5 15. A method as in claim 13 or 14, wherein a floating vehicle probe is selectively 
activated for montoring based on a probability of the traffic unit carrying the probe 
being on a predetennined route-section, 

16. A computer program product comprising program code means ad^ted to 
1 0 control the method of claim 1 . 

•I 

17. A computer system for scheduling traffic capable of planning journeys each 
having a plurality of transit points, the system comprising: 

means for receiving scheduling criteria including transit point data and map 
15 data, said map data comprising one or more routes, each route defined in terms of a 
plurality of route-sections; 

a data repository comprising historical speed data for each route-section, 
historical speed data for a particular route-section being represented for a 
predetennined time on a particular day; 
20 means for generating forecast speed information for a traffic unit on each said 

route-section based on said historical speed data; and 

processing means for planning a journey including a plurality of transit points 
in dependence on said scheduling criteria and forecast speed information. 
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ABSTRACT 
TraBSc S^ ^^ft^nliTiff System 

5 A system for scheduling traffic capable of planning journeys, each having a 

plurality of transit points, comprisinges means for receiving scheduling criteria 
including transit point data and map data, said map data comprising one or more 
routes, each route defibaed in terms of a plurality of route-sections, a data repository 
comprising historical speed data for each route-section, historical speed data for a 

10 particular route-section being represented for a predetermined time on a particular 
day, means for generating forecast speed information for a traffic imit on each said 
route-section based on said historical speed dataa, and processing means for planning 
a journey including a plurahty of transit points in dependence on said scheduling 
criteria and forecast speed information. A method of oporating a traffic scheduling 

15 system and a computer program are also claimed. 
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